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N« 11354*03 



BB 540 o / 210S02 



UEU 

N* D*ENREGISTREMEm' 
NATIONAL ATTRIBUE PAR LMNPI 

DATE DE DEPOT ATTRIBUTE 
PAR L'lNPI 



^ NOM ET ADRESSE DU DEMANDEUR OU DU MANOATAIRE 
A QUI LA CORRESPONDANCE DOIT ETRE ADRESSEE 

CABINET NETTER 
36 avenue Hoche 
75008 PARIS 
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Natlonalrte 
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FRANCE 
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Nom 


PLAQAIS 


Prenom 


Jean-Yves 


Cabinet ou Soci6t6 


Cabinet NETTER 


N **de posivoir permanent et/o" 
de Hen contractu el 




Adresse 




36 avenue Hoche 


Code postal etville 


17 6 lO lO i8l PARIS 


Pays 


France 


N** de telephone (facu!iai0 


01 58 36 44 22 


N** de telecopie (facuMiP 


01 42 25 00 45 


Adresse electronique (jbeu^f0 










Les demandeurs et les inventeurs 
sent les memes personnes 


□ Oui 

W\ Non : Dans ce cas remplir le formulaire de Designation d'inventeur(s) 






Etablfssement imnriediat 
o» etf^blissemfint differft 






Palement echelonne de ta redevance 


Uniquement pour las personnes ph^iques efiecliiant eUe&minies leur propre dSpot 

□ Oui 

□ Non 


^ REDUCTION DU TAUX 
DES REDEVANCES 


Uniquement pour les personnes physiques 

1 1 Requise pour la premiere fois pour cette invention (foindf^unamsde non-imposition) 
1 1 Obtenue anterieurement a ce depot pour cette invention O'o^'^^^^ ^P'^ ^ ^ 
/ii$rixifmd'/zdml9,n'ondl'assislanceprafui^ou$ 1 i i i i 1 


^ SEQUENCES DE NUCLEOTIDES 
ET/OU D'ACIDES AMINtS 


n Cochez la case si ia description content une liste de sequences 


Le support electronique de donnees est joint 

La declaration de conformity de la liste de 
sequences sur support papier avec le 
support electronique de donnees est jointe 


□ □ 


Si vous avez utilise I'imprime «Suite», 
indiquez le nombre de pages jointes 




^ SIGNATURE DU DEMANDEUR 
OU DU EtflANDATAIRE 

(Nom et qualite du signataire) u 

Paris, le 31 decennbre 2003 
Jean-Yves PLAQAIS 
92-1197 (B)(M) 





VISA DE LA PREFECTURE 
OU DE UINPI 



La-loi n*7a-17 du ejanvier 1978 relative- a rinformatique, aux fichifii3-etauxJiherfes^ppliqua-auAjGBpQa3e3.faft^^ 
Elle sarantit un droit d'acces et de rectification pour les donnees vous concernant aupres de nWPI. 




Echange $ecur|se de donnees. notamment- dp. d onnees cerhfiees p niir TaffarhirapA 

5 L'invention conceme I'echange s6curis6 de donnees certifiees, notamment sur un reseau 
etendu conune Internet. 

Dans une technique telle queraffacturage,aestn6cessaked'6tablirun6changeayantvaleur 
juridique entre I'affactuieur et ses clients, les vendeurs, qui ont eux mSme deji 6tabU des 
1 0 factures h leurs propres clients, les acheteurs. 

Traditionnellement, I'echange en question s'dtablit sur papier. Mais il est raanifestement 
souhaitable de le rendre aussi efficace que possible, done de I'informatiser au maximum, 
tout en conservant le caractere certain, la valeur juridique, et aussi la commodite d'emploi. 
Sur le dernier point, la commodite d'emploi, un reseau comme Internet convient bien ; par 
contre, avec Internet, les autres imperatifs sont diffidUes a tenir. 



15 



25 



L'6change de fichiers en ligne sur Internet est aujourd'hui assez bien maJtrise. n en est 
difKremment pour des operations interactives, comme une saisie en ligne, ou il s'agiti 
20 d'6tablir h distance un document de grande taiUe, qui est destine a presenter un caract^re^J: 
certain, a fortiori une valeur juridique. '-^ 

La prfisente invention vient am61iorer la situation. 

Selon un aspect de l'invention, il est propose un systfeme informatique, comprenant : 

- une interface r6seau, propre a initialiser une connexion avec un poste distant, 

- un gestionnaire de m6moire, propre a cr6er et maintenir un espace memoire dedi6 k un 
poste distant, pour I'echange de donnees entre le systdme et ce poste distant, et 

- un gestionnaire de session, r6agissant & une initialisation de connexion avec identification 
reussie en ouvrant une session de poste distant, associee a un jeton unique, et a un espace 
memoire dedie au poste distant dans le gestionnaire de memoire, 

-les6changesde donnees avec le poste distant aucours d'une session aantconditionn6s par 
la presence du jeton associe. 

35 I>ansunmodederealisation,legestionnairedememoireestagencepourdefinirIeditespace 
m6moire d6di6 en tant qu'objet logiciel, associ6 h. I'identifiant et au jeton unique. On peut 
alorsprgvoir un conteneur propre h stocker une correspondance entre des objets logiciels et 
des jetons uniques qui leur sont atfa-ibu6s. 
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De son cote, le gestionnaire de session pent etre agence pour, apres identification renssie, 
rechercher vn objet logiciel correspondant a cette identification, et, sUl en existe, offrir an 
poste distant, comme premier echange avec jeton, la faculte de reprendre une tache sur cet 
objet logiciel, ou de 1' abandonner pour en creer un nouvean associe a une nouvelle tache. 
5 Dans une application particuliere, les taches offertes a un poste distant sont : une fonction 
de saisie de donnees, une fonction de validation de donnees saisie, et au moins une fonction 
de post-traitement apres saisie validee. S'agissant d^une application de saisie a distance, 
offerte au poste distant, Tespace memoire dedie est consacre au stockage temporaire de 
donnees saisies, en attente de validation. Ainsi, le gestionnaire de session peut operer par 
10 envoi au poste distant d'un formulaire de saisie, avec attente d'un retour du formulaire 
complete, a chaque fois accompagne du jeton unique correspondant. Plus precis6ment, les 
donnfies saisies peuvent Stre des donnees de factures, soumises k distance a une entite 
d'affacturage, par un poste distant de vendeur. 

15 Par ailleurs, le gestionnaire de session peut etre agence pour subordonner au moins la 
fonction de validation de factures saisies pour remise en affacturage a une certification 
fondee sur un code personnel (PIN) de la part d'un acteur habilite cote vendeur. 

Selon un autre aspect de 1' invention, le systeme informatique comprend un generateur d'un 
20 fichier natif d^impression, relatif une impression a caractere probant, tiree d'un ensemble 
coherent de donnees presentes dans le systeme, par exemple dans un serveur interne, et un 
gestionnaire de documents capable de tirer de ce fichier natif des impressions orientees 
comptes selon differents formats. 

2 5 Plus particuliferement, le gestionnaire de documents pent comprendre : 

- un accesseur de fichier natif, capable de reagir a un identifiant de document en s61ection- 
nant une portion correspondante du fichier natif, et 

- au moins deux constructeurs de visualisation/impression, capable de cooperer avec 
r accesseur de fichier natif pour construire deux fichiers de visualisation/impression, 

30 correspondant I un meme contenu imprimable, ces deux constracteurs de visualisa- 
tion/impression operant sur des formats de fichier differents. 

Ceci permet de disposer, en interne et chez les vendeurs, de documents directement 
comparables, imprim6s et/ou a Pecran. 

35 

D*autres caracteristiques et avantages de Tinvention apparaitront a Vexamen de la description 
detaillee ci-apres, et des dessins annexes sur lesquels : 



- la figure 1 est un schema de prlncipe general d'un systeme informatique utilisable 
notanraient pour I'affacturage, avec connexion Internet, 

^ - la figure 2 est un schema plus detaille sur le plan structurel du syst^me de la figure 1, 

- la figure 3A est un diagramme de flux de I'entree d'un poste exteme dans un des modes 
possibles de I'invention, en vue plus materielle, 

- la figure SB est un diagramme de flux de I'entree d'un poste exteme dans le mode "saisie 
10 en ligne", en vue fonctionnelle, 

- la figure 4 est un schema plus d6taill6 sur Je plan structurel d'un serveur de la figure 2, 

- la figure 5 est un diagramme du traitement du mode "saisie en ligne" de la figure SB par 
15 un serveur de la figure 2, 

- la figure 6 illustre I'usage de fidiiers natifs d'impression. pour diff6rents formats de 
visualisation/impression, dans un systfeme selon I'une des figures pr6c6dentes, 

V 

20 - la figure 7 illustre le fonctionnement du systfeme de I'une des figures 1 k 4, dans I'exemple^ 
de I'elaboration d'un releve mensuel de gestion. avec pr6paration d'mi ficher natif^ 
d'impression selon la figure 6, t 

-la figure 8 est un schema de flux illustrant le fonctionnement du systfeme selon I'une des 
2 5 figures 1 a 4, dans un autre exemple, qui est l'61aboration d'un document a valeur juridique 
dit "quittance subrogative",et 

- la figure 9 est mi schema de flux illustrant la generation d'un type particulier de fichier 
d'impression. 

30 

dessins et la description d-apres contiemient, pour I'essentiel, des 61ements de caract^re 
certain. Us pourront done non seulement servir k mieux faire comprendre la presente 
invention, mais aussi contribuer k sa definition, le cas ^cheant. 

35 La presente description pent faire intervenir des elements susceptible de protection par le 
droit d'auteur ef/ou le copyright. Le titulaire des droits n'apas d'objection k la reproduction 
a r identique par quiconque du present document de brevet ou de sa partie descriptive telle 
qu'elle apparait dans les dossiers officiels. Pour le leste. 0 reserve int6gralement ses droits 
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Bien qu'elle soit d'application plus generale, Tinvention sera decrite ci-apres dans le 
contexte d'un exemple particulier, qui est Taffacturage, au sens large du tenne. 

L'affacturage consiste en ce qu'une entite ("vendeur"'), qui emet des factures a Tegard de 
ses clients ("acheteurs'*) delegue la gestion de ces factures a une troisieme entite 
("affactureur" ou ^Tiote"). 

La "gestion des factures" comprend a priori : 

- la prise en charge ou "saisie" de la facture par le prestataire, sous la forme des identifica- 
tions requises de la facture, des parties concemees (vendeur et acheteur), et, au raoins du 
cumul facture a chaque fois, assorti en principe d'un d6Iai de paiement, 

- le recouvrement de leur paiement, eventuellement dans les d61ais convenus, au besoin avec 
des mesures de contrainte sur les debiteurs d6faillants, 

- la "consultation des comptes acheteurs**, c'est-a-dire le compte rendu a chaque vendeur, 
en ce qui le conceme, de rex6cution de ce recouvrement, acheteiu* par acheteur, sous forme 
de cumul et/ou dfitaillee, et 

- la gestion par le vendeur des '*profils utilisateur", c'est-a-dire des comptes d'accfes selon 
le vendeur (acces commercial ou acces pour un d6p6t de garanti). 

On comprendra que, pour rh6te, une meme entite peut etre a la fois vendem: et acheteur. Ces 
deux rdles sont naturellement cloisonnes autant que necessaire. 

MaisJaJ!geatiQnJ.^act}xr.ejs^ 

- Touverture eventuelle de lignes de garantie aux vendeurs en fonction des montants qui leur 
sont dus, 

- a cet effet, revaluation de la fiabilite du portefeuille de cr6ances g6x6s par le prestataire 
pour chacun des vendeurs, 

- la "liste des demieres approbations" qui correspondent aux lignes de garantie, 

- la foumiture h chaque vendeur de statistiques sur son activite, vue du c6t6 des facturations 
et de leur r&glement. 

A c6t6 de cela, chaque vendeur peut echanger des messages, par exemple par courriel, avec 
son gestionnaire ou '^contact'* chez rh6te (I'affactureur, dans I'exemple). On observera 
cependant que les intervenants de part et d^autre ne sont pas n6cessairement les raSmes, 
selon la fonction consideree. Par exemple: 

- la saisie des factures est une operation de niveau comptable, 

- a Toppose, la demande de lignes de garantie est une operation de gestion financiere qui, 
au moins du cote vendeur, fera en principe intervenir un "decidcur". 
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Lamise en oeuvre de ces fonctions fait intervenir un systeme infonnatique evolue et s6curise 
du c6t6 du prestataire, 

II est naturellement interessant qu'au moins en partie, les fonctions precitees puissent se 
5 faire par telecommunications entre le vendeur et le systfeme infoimatique du prestataire. A 
cet effet, il a ete possible d'ntiliser : 

- les liaisons de type Minitel (marque deposee), mais dont les capacites sont assez limitees, 

- des lignes de telecommunication specialisees, qui ne sont pas d'application gdnerale a tous 
les vendeurs clients du prestataire, 

10 - les liaisons Internet, qui sont plus puissantes, mais posent diEferents problemes, notamment 
sur la securite et la confidentialite. 

La presente invention a notamment pour but d'am61iorer et d^augmenter les fonctions 
r6alisables par telecommunications, notamment, mais non exclusivement, sur Internet, 

15 

Ainsi, elle vise notannment S permettre i chaque vendeur qui le souhaite, sans investissement 
excessif, de : : 

- saisir en ligne les factures retroc6dees, c'est k dire confides au prestataire affactureur ; J^- 

- consulter non seulement son compte de vendeur, mais aussi le detail des comptes des 
2 0 acheteurs qui le concement ; ' /p 

- rdcuperer une version inf ormatique temoin imprimable de tous les documents comptables 
et annexes requis ; 

- echanger electroniquement avecThote affactureur des documents ayantvaleur legale, tels 
que ceux dits "quittance subrogative", avec en option la possibilite d'une gestion 

25 automatique des deblocages de fonds, qui sont alors avances au vendeur. 

n est maintenant fait r6f6rence a la figure 1. Un systeme inf ormatique hote applicable a 
Taffacturage pent se composer d'un serveur principal 10, (Srvl), associ6 ^ diff6rents autres 
serveurs, ici un serveur 20 (Srv2), et un serveur 30 (Srv3). 

30 

n peut etre egalement prevu un serveur d'application, qui permet I des postes internes 
d'acceder aux donnees. Le poste 60 est par exemple un poste d'op6rateur interne qui sert a 
gerer des comptes vendeurs. 

35 Un serveur Internet (IIS Srv) 50 permet a des postes extemes tels que 91 et 92, d'acc6der ^ 
la partie restreinte des informations qui les concement. On decrira plus loin comment cette 
restriction est effectuee. 

Le serveur 10 contient par exemple : 
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- les doim6es relatives k la tenue des comptes, notamment la liste des factures et des 
operations diverses, 

- les fonctions permettant la consultation par les vendeurs de leurs comptes, 

- le suivi des encours, compte tenu des rdglements d'acheteurs, regus par raffactureur, sur 
5 des factures de vendeurs. 

Le serveur 20 contient, par exemple, les demandes de garantie par les vendeurs, en fonction 
de I'encours des acheteurs, la gestion du disponible, ainsi que des tables de reference, par 
exemple des tables de devises, pays, codes d'operations. 

10 

Le serveur 30 contient des informations d'image, des informations statistiques utiles k , ainsi 
que les fonctions relatives a la saisie en ligne des factures. 

La figure 2 illustre un exemple d'architecture mat6rielle correspondant au systfeme de la 
15 figure 1. 

Cette figure 2 fait apparaitre les m€moires de masse (disques durs, par exemple) 11, 21, et 
31, respectivement assodees aux serveurs 10, 20 et 30. 

20. La structure est un peu diflBSrente de celle de la figure 1, en ce sens que les fonctions du 
serveur d' applications 40 de la figure 1 sont maintenant contenues dans le cadre en trait 
tiret6 40, qui comprend: 

dfrsdtg^ser^'eurint^Hiet^Q^e^pplicat i . o n 41 de . services en U gne,.(dltfe:!Eac.tQne.t...dllO^ 

avec une interface de communication 42 (DCOM) vers le serveur 30, et une autre interface 
25 de communication 43 (TCP), qui communique avec le serveur 10; 

- du c6te du serveur 10, une pile TCP 44, suivie de I'interface de communication generale 
45 de ce serveur 10, puis d'une fonction 46 (dite VIDOlOO) faisant le pendant de 
I'application de services en ligne, existant dans le serveur 30; 

- dgalement du c6t6 du serveur 10, une couche de communication 47, permettant aux postes 
30 internes, comme 60, d'acceder au serveur 10. 

Ainsi, les edianges portant sur revolution de donn6es 66}k 6tablies (certifi6es cote vendeur) 
peuvent se produire directement entre le serveur internet 50 et le serveur 10. Par contre, dans 
I'exemple d6crit, les 6changes de donn6es h certifier sont trait6s differemment, a I'aide du 
3 5 serveur 30, comme on le verra ci-aprds en detail. 

La figure 2 fait 6galement apparaitre que le serveur 10 est muni d'un environnement de 
programmation procedurale 12 (PP), fonde par exemple sur le langage Cobol. Cet 
environnement est apte a traiter des objets sous forme procedurale. 
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Dans I'exemple, la saisie en ligne de factures, une fois tennm6e, va s'accompagner d'un 
^change certifie qui d61fegue k I'hdte affactureur la charge de recouvrer les factures list^es. 
Cette delegation certifi6e est appelee une "quittance subrogative". C'est un document 
juridique, qui pourra 6tre confirme par la transmission separ^e d'un document papier dument 
5 signe. II est bien entendu essentiel que la saisie en ligne et le document papier soient rendus 
autant qUe possible identiques en substance. Et ceci pose d'abord le problfeme de la saisie 
sure, en ligne, du document imposant que constitue gdn^ralement la quittance subrogative. 
En effet, un nombre d'une centaine de factures mensuelles subrogees est courant. 

10 La demanderesse a resolu ce probleme en prevoyant dans un serveur, ici le serveur 30, une 
zone memoire d6diee a la saisie en ligne pour chacun des vendeurs. Lorsque la quittance 
subrogative est tennin6e, et validee, les factures subrogees passent dans le serveur 10 par 
une communication groupee asynchrone entre un module batch 3 du serveur 30 et un module 
batch 1 du serveur 1. Le serveur 10 et le serveur 20 peuvent ensuite se servir de ces factures 

15 subrogees. 



La demanderesse s'est pr6occupee de defmir une identification stable entre le poste'- 
"vendeur" distant, pouvant gtre celui de Pemetteur des factures, et le systfeme informatique ^ 
h6te. n s'est av6r6 que I'adresse Internet (ou autre adresse r6seau) n'est pas satisfaisante, du . 
fait que des postes vendeurs peuvent Stre assoqi^s a un foumisseur d'accfes Internet s6curise, 
qui change I'adresse Internet dynamiquement, par exemple g chaque connexion. ' 

La demanderesse a rdsolu ce probleme en utilisant un systfeme k jetons multiples. 

Lafigure 3A illustre 1' entree en session d'un poste vendeur, en vue "mat6rielle", c'est-i-dire 
pour les aspects de plus bas niveau (jeton) de la connexion. 

En 310, un vendeur accfede, ici par Internet, au site bote, en I'espece : 
https://www.facto.fr/factonet 

A I'operation 312, 1'operateur du vendeur foumit un identifiant et un mot de passe de 
maniere s6curisee (par exemple par cryptage dit SSL ou "Secure Socket Layer"). C6te h6te, 
a rop6ration 313, il est proc^de k une validation de I'identification du vender. Ced 
s'effectue ici par une fonction de type «dll", d6nommee par convenance DLL factonet Si 
la validation est positive, la fonction DLLcree et renvoie de maniere s6curisee (par exemple 
par cryptage SSL) au vendeur, en 315, un jeton unique d 'identification, note 315T. 

Ce jeton peut etre calcule comme une fonction aleatoire de la date, de I'heure et d'une valeur 
comprise entre 0 et 9999 par exemple, en preservant au besoin son unicit6 par un mdcanisme 
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anti-doublon, de manifere cx>imue. Un exemple de jeton est donn^ 3ZBYEYBW04355865 
dans lequel le jeton est la concatenation du resultat d'une fonction aleatoire sur la date 
(3ZBYEYBW), de Theure (04:35) et d'nne valeur aleatoire. Un tel jeton, combine au 
cryptage SSL, foumit de f agon commode a la fois une bonne securisation des transmissions, 
et une bonne isolation de celles-ci, d'un vendeur a P autre. Ces aspects ont ete importants, 
pour permettre a la Demanderesse de mettre en oeuvre une saisie des factures subrogees en 
ligne. 

Ensuite (316), poin chaque demande de fonction par le poste vendeur, cette demande (317), 
accompagnee du jeton 315T, est adressee k la fonction factonetdll notee ici 319, et la 
reponse 318 est accompagnee du meme jeton. Le cryptage SSL peut etre utilise, conmie 
precedemmenL Cette demande de fonction pent concemer par exemple P une des f onctions 
suivantes, qui peuvent etre offertes en menu : 

- la saisie en ligne a rop6ration 320 

- Tapprobation de credit k Toperation 321, 

- la visualisation des comptes k 1' operation 322. 
Une telle demande de fonction peut avoir la forme: 
https://www.facto.fr/scripts/factonet.DI^^ 

oil r expression menu? designer une des fonctions requise par 1' operateur du vendeur, et oil 
Texpression <Jeton> repr6sente le jeton. 

La figure 3B illustre plus particulierement le cas d'une fonction de saisie requise par un 
:^iendeur-^mme-^indiqueJulioperatian-320-d^^^ 

certification n ' appartiennent pas a la meme personne. De plus, des intermptibns, volontaires 
ou non, peuvent se produire dans la saisie. 

Les operations 310 et 312 de la figure 3A correspondent aux op6rations 300 et 302 de la 
figure 3B. 

Un poste distant entrant (300) indique (302) son identif iant id_vendor de maniere securis6e 
(communication de type SSL). Les op6rations 313 a 320 de la figure 3 A se d6roulent. Ainsi, 
apres validation de T identification du vendeur (313) par la fonction DLL, un jeton est 
renvoye (315) de mani&re securisee au serveur 50, ce jeton jouant le r61e de T identifiant de 
I'etat en cours de la session du vendeur. Si Toperateur du vendeur requiert la fonction de 
saisie (320), le serveur 50 transmet Tidentifiant du vendeur et le jeton au serveur 30, qui 
recherche (304) s'il existe en memoire pour ce vendeur un bordereau de saisie commence 
lors d'une session precedente. En variante, ce peut etre le serveur 50 qui verifie si un 
bordereau est deja present en memoire. Dans le cas ou il existe un bordereau commence et 
non termine, la session precedente et son etat d*avanccment ont ete identifies en memoire 



9 



respectivementparridentifiant du vendeur et un jeton. L*usager distant est alors invit6 (306) 
a decider de reprendre ce travail precedent (307), ou d'en entamer un nouveau- Dans ce 
dernier cas, le travail precedent pent etre annule et d6truit (308), et Tusager entamera la 
saisie d'un nouveau bordereau de factures (309), Bien entendu, si le test 304 n'indique pas 
5 de travail precedent, Tusager passe directement en 309. 

Ce mecanisme permet une securisation satisfaisante de la saisie, tout en evitant a I'usager 
de tout recommencer si une session est interrompue, volontairement ou non. On observera 
que les donnees saisies sont rntegralement stockees en direct chez Phote, 

10 

La figure 4 illustre un mode de fonctionnement par jetons pour des acces internet. Sur cette 
figure est represent^ le serveur Internet 50 comprenant rapplication 41 DLLFactonet, avec 
Tinterface de communication 42 (DCOM) vers le serveur 30, et une autre interface de 
commimication 43 (TCP), qui conmiunique avec le serveur 10. L' application 41 est plus 
1 5 particulierement detaillee ci-apres- 

L'application 41 comprend un module Web 410 en relation avec le serveur 50 d'tm cotd et 
une librairie de fonctions 412, appel6es objets fonction, de Tautre. Le module Web appelle 
les fonctions de cette librairie. Le module Web comprend un repartiteur (ou dispatcheiu:) 
2 0 adapte pour repartir sur les bonnes interfaces de conmiunication les dijfferentes demandes 
de fonction des vendeurs, 

Le module Web 410 valide T identification d'un vendeur et appelle une fonction de la 
librairie 412 afin de calculer im jeton pour vm vendeur donne et une session donn6e. Le 

25 module Web 410 attribue le jeton calcule et le renvoie au serveur 50. Le module Web agit 
a ce stade conmie un gestionnaire de memoire, agence pour definir un espace m^moire 
dedie, en tant qu'objet logiciel, associe k I'identifiant et au jeton unique. Ainsi, il cree un 
objet vendeur qui permet de stocker Thistorique d'lme session de vendeur, et V enregistre sur 
un disque 419 k entree/sortie temporaires, chaque objet vendeur comprenant I'identifiant du 

30 vendeur, De plus, le module Web stocke temporairement dans un conteneur qui pent Stre 
une table 414 chaque pointeur d'un objet vendeur et son jeton associe. Ainsi, un jeton 
permet d'identifier la session du vendeur correspondant a Tobjet vendeur. Autrement dit, 
le conteneur stocke une correspondance entre des objets logiciels et des jetons uniques qui 
leur sont attribues. 

35 

Si Toperateur du vendeur n'effectue aucune action durant une session pendant un temps 
donne, par exemple 15 minutes, un processus de nettoyage 416 intervient pour detruire le 
jeton correspondant, le pointeur d'objet vendeur dans la table 414. Le module Web permet 
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6galement de gerer les demandes r6petees et non encore satisf aites des vendeurs en envoy ant 
un message d*attente au vendeur. 

Lors d'une demande de fonction par Poperateur du vendetir, le module web utilise une 
fonction de la librairie 412 afin de commnniquer cette demande de fonction an serveur 
adequat : 

- si Toperateur du vendeur demande une saisie en ligne, la communication de la demande 
sera faite par Tinterface de communication 42 (DCOM) vers le serveur 30, 

- si Toperateur du vendeur demande une visualisation de ses comptes, la communication de 
la demande sera faite par Tinterface de communication 43 (TCP), qui communique avec le 
serveur 10, 

- si roperateur du vendeur demande une approbation de credit, la communication de la 
demande sera faite par Tinterface de communication 43 (TCP) vers le serveur 10. 

La demande de fonction est envoyee avec le jeton de la session courante du vendeur. La 
reponse renvoyde k 1' application Factonet DLL 41 comprend 6galement le jeton de la 
session. 

A titre de generalisation de la figure 3B et en rapport avec la figure 4, le module Web peut 
rechercher, apres identification d'un vendeur et creation d'un jeton pour la session en cours 
du vendeur, si Fidentifiant de ce vendeur se trouve dans un precedent objet vendeur 
correspondant a une precedente session et ceci a partir du conteneur qui pointe sur les objets 

vendeurs-st0e4£esr^A3nsir-si--laHFe^ier^b^ 

ridentifiant du vendeur, un nouvel objet vendeur est cree pour la nouvelle session et le 
module Web attribue k cet objet vendeur le jeton courant. Si la recherche aboutit a trouver 
un objet vendeur comprenant ridentifiant du vendeur et que Toperateur du vendeur valide 
la creation d'un nouvel objet vendeur pour la nouvelle session, cet objet vendeur est cree et 
le module Web attribue le jeton courant a cet objet vendeur, L'operateur du vendeur ne 
beneficiera pas de Pobjet vendeur de la session anterieure qui pourra 8tre d6truit. Au 
contraire, Toperateur du vendeur peut valider la reprise de Tobjet vendeur stocke sur le 
disque de fagon a ce que l'operateur du vendeur reprenne et complete la session anterieure. 
Dans ce cas, le module Web attribue le jeton courant h cet objet vendeur de la session 
anterieure. 

Le modiile web agit ici comme \m gestionnaire de session qui est agenc6 comme suit : apres 
identification reussie, il recherche un objet logiciel correspondant a cette identification, et, 
s'il en existe, il offre au poste distant, comme premier echange avec jeton, la faculte de 
reprendre une tache sur cet objet logiciel, ou de Tabandonner pour en creer un nouveau 
associe a une nouvelle tache. Ceci peut servir, notamment, pour la saisie a distance. 



La figure 5 iUustre le traitement de la demande d'une saisie de facture h subroger en ligne 
du vendeur par le serveur 30 sur demande de I'appUcation Factonet DLL 41 de la figure 4. 

L'operateur du vendeur entre les principaux elements de la facture en cours de saisie (502). 
Le serveur 30 de la figure 2 verifie si Tacheteur est deja connu, par exemple dans une table 
des acheteurs associ6s au vendexir saisissant la facture (504). 

Si racheteur est dejl connu, l'operateur du vendeur pent selectionner, dans une liste 
d'acheteuis, les details concemant cet acheteur (508) afin d'etablir une facture detaill6e. 
Sinon, le serveur 30 verifie si l'operateur du vendeur a entre des informations detaillees 
concemant I'acheteur (506). Dans la negative, le serveur demande au vendeur d'entrer les 
informations minimales concemant I'acheteur (516); dans I'afQrmative, il est demande au 
vendeur s'il souhaite avoir I'assistance de recherche de I'acheteur (510). Si I'assistance est 
requise. l'op6rateur du vendeur re§oit une fengtre de saisie de I'acheteur avec des zones pr6- 
rempUes (512) puis complete la fenStre de saisie par des informations acheteur et valide la 
fenetre (514). Si I'assistance n'estpas requise, l'operateur du vendeur regoitune fenStre de 
saisie de I'acheteur et la fenStre de saisie par des informations acheteur et valide la fengtre 
(514). Ces informations sent conserv6esparIe serveur 30 sur son disque. Cette fengtre pent 
gtre rattach6e k la liste des acheteurs de I'opgration 508. 



Apths l'op6ration 508, 514 ou 516, l'operateur du vendeur valide la facture(518) par son 
enregistrement et le serveur 30 peut le stocker sur son disque. Durant une meme sessioii; 
l'operateur du vendeur peut entrer et valider d'autres factures pour un mgme cUent ou 
d'autres cUents (520), le diagramme recommengant alors en 502. Si aucune autre facture ne 
doit etre saisie (520), le serveur 30 execute le traitement final de la facture comme illustr6 
par le figure 8. 

La figure 8 illustre la phase finale de certification des 6I6ments saisis, toujours dans 
rexocQple d'une quittance subrogative. 

Une fois la facture enregistr6e et validge, les instmctions concemant le r&glement de la 
fecture sont saisie par l'operateur du vendeur (524). Une empreinte est etablie (526) et le 
code PIN (Personal Identification Number) du vendeur mscrit sur une carte du vendeur est 
saisi (528). La carte de certification peut Stre par exemple du type "Click and trast", garanti 
par un tiers de confiance. La certification (530) de la facture est gtablie par l'operateur du 
vendeur si celui-ci peut certifier la facture. Si l'operateur du vendeur n'est habflite qu'a 
saisir une telle facture, la certification de la facture subrogee est effectuee par une autre 
personne habilitee du vendeur, apres identification de cette demiere par sa carte. L'op6rateur 
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du vendeur ou la personrie habilitee a certifier la f acture et sa subrogation donne son accord 
pour la subrogation de la facture (532). 

Un fichier d*ensemble des factures subrogees est genere (534). II peut servir de base pour 
construire un fichier d' impression, par exemple au format PDF (540), cote hote. Ce fichier 
est envoye au vendeur, qui Timprime (542). Une personne habilitee du vendeur retourne 
alors le document imprime sign6, par exemple par telecopie classique ou par courrier. Ainsi, 
si besoin est, le document juridique certifie en ligne peut ainsi etre confirme par la 
transmission separee d'un document papier portant une signature ecrite classique (544). 

Optionnellement, un financement peut etre demande des la certification des factures, comme 
le rappelle T operation 538, 

En parallele, le fichier contenant Pensemble des factures saisies et subrogees est envoye du 
serveur 30 au serveur 10 par une communication 536 par exemple par lots (en batch 536) A 
partir de la, les factures subrog6es peuvent etre trait6es par le serveur 10. En bref, a partir 
des factures subrogees, Thdte afifactureur peut, de maniere connue, mettre en oeuvre 
diff6rents traitements, pour lui-meme et pour I'operateur du vendeur, son client. 

D'autres types d'echanges entre le systeme informatique hote, et les postes vendeurs 
distants, ainsi que les postes intemes de Thote, sont illustres sur la figure 7. II s'agit 
notamment : 
----dexomptesdceiidus-smJl!fi3m^ 
quel acheteur a paye dans les delais, ou quel acheteur n'a pas encore paye. 

- de demandes de garantie 704 en amont d'une commande acheteur a un vendeur, 

- de donnees statistiques 706. 

Tout cela doit : 

- correspondre exactement aux donnees securisees introduites dans le systfeme informatique 
hote, 

- permettre de deteraiiner un 6tat coh6rent des choses, au vu des differents intervenants 
(vendeurs, acheteurs, hote), 

- pouvoir 6tre visualise/imprime d'une mani&re stable, 

- pouvoir 6tre archiv6 avec un encombrement aussi r6duit que possible. 

Les deux premiers points sont unportants, mais rel&vent naturellement du savoir-faire de 
Taffactureur. On notera que les controles correspondants sont faits en parallele, et que le 
resultat de chacun de ces controles peut arriver de fagon tout a fait asynchrone, par rapport 
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au moment oil I'hdte decide de "fixer" un etat coherent, pour lui m6me, ou pour un ou des 
vendeurs. Ainsi quali£[6, le probleme devient : 

- accumuler des donn6es de fagon non ordonnee, 

- pouvoir les visualiser/imprimer d'une maniere stable, 

- pouvoir les archiver avec un encombrement aussi reduit que possible. 

On decrira maintenant comment ce probleme a ete resolu, k partir d'un jBchier de base que 
Ton appelle ici "fichier natif' ou "jSchier g^nerique". 

La figure 7 d6crit I'elaboration d'un fichier natif decrit ci-dessous. 

Diverses informations sent requises pour elaborer un fichier natif associe a un vendeur: 
revolution des comptes des acheteurs 702 pour ce vendeur, les demandes de garantie 704 
de ce vendeur, les donn6es statistiques 706 relatives aux informations concemant ce vendeur 
et d'autres informations stock6es dans une mdmoire 700. Chacune de ces informations est 
trait^e par le serveur 10 sous la forme de flux d'informations respectivement 720, 740 et 
760. D'autres flux d'informations peuvent 6tre pris en compte, et sont consultables & partir 
d'une m6moire 710. Des processus appropries, par exemple en batch, permettent de traiter^ 
(770) ces flux d'mformations afm de construire un fichier natif (600) pour ce vendeur. Les 
fichiers r&ultant peuvent Stre adress6s au vendeur h travers I'application FactonetDLL41 v 
de la figure 4, de I'une des mani^res d^crites. 

Dans I'exemple, le fichier natif est un fichier k emegistrements Oignes ou rang^es) de 
longueur fixe. II comprend : 

- un enregistrement de tete dont la structure est donnee dans la table 1 annex6e ; 

- un nombre variable d'enregistrements utiles ("corps"), dont la structure est donn6e dans 
la table 2 annexee ; et 

- un enregistrement de fin dont la structure est donn6e dans la table 3 annexee. 
Pour le corps, chaque rangee comprend: 

- un second identifiant de compte vend_id, 

- un identifiant de type de document (de visualisation/nnpression) Doc_/xpe, 

- des informations de presentation dans le document, id : 

* un num6ro de page PageNoIriDefc 

* un choix de rtcto-VQiso PrintSide 

* des informations de position Data _pos 

* des informations d'attributs d'unpression PrintAttrib 

* des informations de saut de ligpeLineJump 
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* des pointeurs d'informations d'elements graphiques k inserer Graph_elmts 

- une zone de remplissage filler ^ et 

- une zone de donn^es (de visualisation/impression) Dataj:ontent 

Le corps peut 6galement comprendre xme rangee defmissant un premier identifiant de la 
societe d'affacturage socjd. 

Dans Texemple, les donnees a visualiser/imprimer peuvent etre definies : 

- par la zone^ Data content, une chaine de caracteres, et/ou 

- par un pointeur vers un autre element de donnees, par exemple graphique, comme 
Graph^elmts. 

La valeur de Datajzontent peut etre du type caractere, implicite par convention. Dans ce cas, 
les autres types de donnee a imprimer peuvent Stre convertis en caractferes pour etre ainsi 
notes enDatajzontent En variante, Data^content peut contenir aussi, par exemple en tete, 
un code definissant le type de donnees contenues h chaque fois dans la zone Data^content, 
Si cela est desire, les autres types de donnee peuvent &tre aussi dejSnis a travers un pointeur 
stocke dans Data_content. 

La demanderesse a observ6 que cette structure reste assez simple pour loger en s6curite de 
grandes quantites de donnees de visualisation/impression, arrivant en flot melange quant au 
document vise, quant au temps, et m8me quant a differentes parties d'un meme document. 



iJa-teljacMeJV^ree^njaot,4^ — 

II est borde en tete par un enregistrement de debut (Table 1) comportant ici les informations 
utiles suivantes: 

- une date de creation du fichier CreatJOate 

- une date d'effet du fichier jBjfecl^Da^e 

- une information de classe de fichier i^ife^c/o^^, par exemple la classe Releve Mensuel de 
Gestion (RMG) definissant un ensemble de documents ^ destination des vendeurs, la classe 
Relev6 de Notification Acheteur (RNA) definissant un autre ensemble de documents, a 
destination cette fois des acheteurs, 

L' enregistrement de debut comporte egalement a titre optionnel : 

- socjdj d6]k cit6e. 




L' enregistrement de fin (Table 3) est semblable a T enregistrement de debut. Dans Texemple, 
les informations de dates et classe de fichier sont remplacees par un nombre 
d*enregistrements NbOfRec. 
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Reste la zone de tete de chaque enregistrement rec_code, qui vaut 1 pour I'enregistrement 
de tgte, 9 pour I'enregistrement de fin, et, pour les enregistrements de corps, une valeur 
allant de 2 a 4, pour indiquer (dans Texemple) si renregistrement concern^ est destine a la 
visualisation, ^ I'impression, ou aux deux (les valeurs 518 sont r6serv6es). 

On observera que le fichier natif peut contenir en th^orie jusqu'i 100 millions 
d'enregistrements (10«), ce qui, pour 241 caract^res par enregistrement, lui donnerait une 
taiUe de 24,1 Gigaoctets environ. En pratique, la Demanderesse a utilise en test un fichier 
de 500 Megaoctets environ, couvrant plus de mille vendeurs. 

L'une des tSches incombant aux afifactureurs est de produire un "releve raensuel de gestion", 
qui doit 6tre adress^ h. ses clients, les vendeurs, pour consultation, impression et/ou' 
archivage. On considdre maintenant cet exemple du "relev6 mensuel de gestion". 

Le relev6 mensuel de gestion est definit par un ensemble de documents envoyes au vendeur 
et comprenant par exemple : 

- des lignes de garantie attribu6e au vendeur, 

- le compte courant du vendeur, 

- les factures subrogees qui sont «en exception", par exemple les factures qui sont en retard^ 
de paiement. , I. 

Le vendeur peut simplement demander une garantie, g6rer lui-m6me les factures et se servir 
du releve mensuel de gestion pour detecter notamment les factures en retard de paiement 
Ce releve mensuel de gestion peut etre elabore a partir d'un fichier natif. 

La figure 6 utilise un fichier natif 600, elabore par exemple comme indique ci-dessus. Le 
flot d'entr6e qui nourrit le fichier natif est ici sous le controle d'un gestionnaire de fichier 
natif 602. 

Ainsi, selon un autre aspect de l-invention, il est pr6vu un g6n6rateur d'un fichier natif 
d'impression, relatif une impression I caractdre probant, tir6e d'un ensemble coherent de 
donnges pr€sentes dans le serveur interne, et un gestionnaire de documents capable de tirer 
de ce fichier natif des impressions orientees comptes (vendeurs) selon diff^rents formats. 

Le ficher natif (ou fichier g6nerique) 600 peut servir k diflSrentes sortes de visualisa- 
tion/impression, a I'aide d'un outil d'acces(«accesseur»)i ce fichier 605, que I'on appellera 
ici extracteur. 
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L*utilisation la plus simple du fichier natif est la preparation des releves mensuels de 
gestions individuels pour tous les vendeurs, 

De maniere connue, Textracteur est agence coimne une fonction qui regoit une ou des 
5 conditions de filtrage applicables aux enregistrements de corps (ou lignes) du fichier natif. 
En reponse, cette fonction est capable d'isoler toutes les lignes du fichier natif qui verifient 
la ou les conditions de filtrage. Dans le cas d'une impression, le filtrage sera en outre limite 
aux lignes dont le rec joode est 3 ou 4 ; ceci pent etre defini par la nature de la requete. 

10 De preference, la fonction utilise aussi un ou des criteres de tri, qui peuvent etre predefinis 
ou regus par la fonction comme second parametre (en plus du premier parametre que 
constituent les conditions de filtrage). 

Une condition predefinie de tri particulidrement interessante est : 
15 - tri primaire par vendeur (yend_id)^ 

- tri secondaire par position dans le document, k savoir, en principe dans Tordre : 

* numero de page PageNoInDoc 

* choix de recto-verso PrintSide 

* informations de position Data jpoSy et 

20 * autres donnees de position tirees eventuellement des informations d'elements 

graphiques a inserer Graph_elmts, des informations de saut de ligaeLineJump^ et 
de la longueur effective du champs de donnees util&s Dataj^ontent. 

Bien entendu, des requetes plus precises peuvent egalement etre effectuees, par exemple si 
25 un poste interne de Thote desire visualiser ce qui concerne un vendeur precis. 

En bref, pour visualiser/imprimer un etat, le systfeme informatique doit seulement foumir 
une requete, traitee par le requeteur 607. Celui-ci pent alors fournir les donn6es correspon- 
dant a la requete. Celle-ci pent porter seulement sur la zone Docjype, comme deja decrit 
3 0 pour simplifier. En pratique, Docjype est seulement un identifiant de type de document, par 
exemple un "releve mensuel de gestion", qui peut 6tre de portee globale, mais se 
decomposer en autant de fichiers cibles qu'il y a de vendeurs traites. 

Par contre, si Ton se limite 2L un vendeur donne les donnees a visualiser/imprimer ne sont 
35 completement determinees que par un doublet (yendjd, Docjype). 

Des criteres de selection supplementaires peuvent etre mis en oeuvre apres la premiere 
selection sur Docjype:, ou bien en meme temps que celle-ci. Des index peuvent etre utilises 
pour accelcrer le travail de Textracteur 605. 
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Dans I'exemple, la figure 6 fait apparaitre trois constracteurs de fichiers de visualisa- 
tion/impression de formats differents. 

Le constructeur 610 elabore ici des fichiers, par exemple "pdf' , assurant une presentation 
5 stable pratiquement quel que soit le peripherique d'impression (et/ou de visualisation). Ceci 
peut constituer des fichiers de taille raisonnable, compatible avec une transmission rapide 
au "vendeur" par Internet. En variante, pour les vendeurs "Grands comptes", il serait 
concevable de leur envoyer I'extrait du fichier generique qui les conceme, tandis que le 
constructeur 610 serait implante dans Tinformatique du vendeur. 

10 

Le constructeur 620 61abore ici des fichiers image, par exemple "tiff", assurant une 
visualisation stable et confortable, pratiquement quel que soit le peripherique de 
visualisation, pour des personnels de I'hdte utilisant h plein temps les ecrans. La creation 
des fichiers image, par exemple "tiflE", k partlr du fichier g6nerique est consideree comme 
1 5 accessible h I'homme du m6tier. 

Le constructeur 630 elabore ici des fichiers, par exemple au format dit VIPP (Variable Data 
Intelligent Postcript Printware), compatible avec une impression stable et de haute qualite,": 
qui peut 6tre confi6e en sous-traitance. Ici, la rapidit6 n'est pas primordiale, compte-tenu du ^ 
20 temps requis pour I'impression qui va suivre. 

II est important de souligner que tout ceci peut se faire k tout moment, sur la base d'un 
fichier natif simple, done facile k archiver. 

25 La figure 9 illustre un mode de r6alisation de la lecture d'un fichier natif par un constructeur 
de fichier de visualisation/impression. 

Le fichier d'entr6e k lire est tout d'abord ouvert en 810 et la lecture de ce fichier commence 
en 812. Dans cet exemple, le fait que le fichier d'entree peut effectivement servir comme 
3 0 fichier natif (pour traitement par le constracteur de fichier conceme) est indique par une 
variable codenr mise k "1". Le processus se termine done en 830 si la variable codenr est 
differente de 1. Cette variable codenr reflate le code "1" (rec_code) contenu dans 
I'enregistrement de tgte d'un ficher natif. Si la variable codenr est egale k 1, le proc6d6 se 
poursuit a I'opgration 816. 

35 

II est rappele que le code File_class de I'en t6te du fichier natif range le document dans une 
classe particuliere. L'ensemble des classes possibles de document peut etre stocks dans une 
table, notee "Tabl24", qui definit aussi quels types d'impression sont pr6vus pour chaque 
classe de documents. L'op6ration 813 inspecte cette table "Tabl24", afin de determiner si 
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le fichier natif d'entree a vocation k etre trait6 par le constructeur de fichier de visualisa- 
tion/impression consider^ (id, I'un des constructeurs 610, 620 et 630). Si ce n'est pas le cas 
(818), le processus se termine en 830. 

5 Si au contraire la table Tabl24 accepte en 818 la classe de document du fichier natif en 818 
pour le constructeur de fichier de visualisation/impression considere, la lecture du fichier 
natif se poiursuit en 820, tant que la fin du fichier n'est pas atteinte (test 822). 

En principe, dans une passe, seuls les enregistrements relatife a un vendeur donne (code 
1 0 vend_id) sont consideres. 

A chaque pas de lecbare, on examine en 824 la valeur du code enregistrement recjcode, pour 
determiaer s*il correspond au constructeur concerne. Ici, un recjoode 2 ou 4 autorise les 
constructeurs de fichiers 610 et 630 ; un recjcode 3 ou 4 autorise le constructeur de fichier 
15 image 620. 

On examine egalement la valeur du cxydo Doc JType en 824, de fagon k 6tablir les limites de 
"dossier", dans le fichier. 

20 La ou les codes voulus sont trouves en 824, la mise en forme pour impression peut etre f aite 
en 826. Cette mise en forme sera dficrite plus loin. 

XaJecture-du-ficbi^^^iatif^entin^-^isu^ e nreg is trement 
qui a la valeur edition en 824 et ceci jusqu^a la fin du fichier en 822. Des que le fichier natif 
est entierement parcouru, on peut afficher en 828 le nombre de dossiers mis en forme k partir 
du fichier natif. Le precede se termine a Tetape 830. 

Dans le cas de I'elaboration d'lm fichier au format pdf a partir d'un fichier natif comme 
decrit ci-dessus, la mise en forme consiste a priori k creer Ten tete specifique d'un fichier 
3 0 pdf. Chaque passage a Toperation 826 peut se faire en generant, a partir des zones utiles a 
I'impression de Teiu-egistrement concerne du fichier natif, les parametres voulus pour un 
appel d'un outil du commerce, comme le pilote "Adobe PDFwriter". Ainsi, la Demanderesse 
a pu ecrire sous DELPHI (Borland) im module d6nomme "rasterPDRexe" fonde sur le 
diagramme de flux de la Figure 9. 

35 

Dans le cas de Telaboration d'un fichier au format VIPP a partir d'vm fichier natif, la mise 
en forme consiste principalement a ecrire differentes declarations, qui sont fonction des 
donnees du fichier natif, et du contexte. 
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Dans le cas du format VIPP, 6crire une declaration consiste a 6crire dans le fichier un objet 
declare, puis ecrire les attributs gen6raiix concemant cet objet, et ecrire la fin de cette 
declaration. 

Ainsi, la mise en forme proprement dite fait intervenir une declaration d'en tSte (dite XRX) 
pour I'edition sous format VIPP, suivie des attributs generaux de r6dition, puis d*une "fin 
de declaration XRX". 

D'autres types de declarations peuvent 6tre ecrites, notamment pour : 

- le debut (START) du fichier au format VIPP, 

- ce qtii est relatif au code natif, 

- I'orientation du papier, 

- rimpression recto/verso, ou non, 

- les marges d'impression. 

Lorsque des ruptures sont detectees, differentes mesures sont prises, selon la nature de la 
mpture et le contexte, / 

Ainsi, lorsquHme rupture de type de document est rencontr6e : 

- une table des donn6es signaletiques du document est lue, 

" des declarations de type de "bac d'alimentation papier k utiliser" sont ecrites, 

- des declarations du d6but d'edition en recto ou en verso sont ecrites, 

- des contrSles de polices et de logos a utiliser sont effectues- 

LorsquHin changement de page est detecte: 

- un controle est effectu6 pour un 6ventuel changement de bac d' alimentation papier, 

- des declarations de codes de changements de page sont ecrites. 

Lorsqu^un changement de donnees est detecte : 

- une table des caracteristiques des donn6es est lue, 

- des declarations d'alignement sont ecrites, si le paragraphe est justifie, 

- des declarations des coordoimees d'affichage/impression de la donnee sont 6crites. 

D'autres 6critures de declarations sont disponibles notamment pour declarer un nombre de 
iignes d'espacements, et, sur lecture d'une table des caracteristiques de la police, declarer 
le nom de la police, sa taille, Tinterlignage, le soulignement au besoin. 
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D'autres interventions possibles consistent en la transformation de certains caracteres (ceux 
qui sont utilisds comme commande dans le format VIPP), ou encore en l'6criture des 
declarations du type d'alignement dans le cas d'nn nouveau paragraphe. 

Dans le cas d'un element graphique : 

- les caracteristiques de I'element graphique sont lues dans une table, 

- les d6clarations.de la donnee du fichier natif sont ecrites. 



) 



Le fichier se termine par des declarations de fin d'6dition au format VIPP. 

II est raaintenant possible de r6sumer I'application de linvention k I'affacturage. 

On considfere un "vendeur", qui a pass6 xm contrat g6neral d'affactiirage avec I'affactureur 

5 Ensuite, le vendeur peut d616guer ^ un op6rateur comptable la saisie des factures k d61eguer 
a raffactureur. Cette saisie s-effectue en direct & partir d'un poste distant, sur un r6seau 
6tendu commeIntemet.Apres identification deroperateur,doncduvendeur,unjetonunique 

est utilise pour obtenir une saisie en Ugne sfire, k la fois entre operateurs de diff^rents 
vendeurs, et au niveau d'^ventuelles ruptures ou anomalies de transmission. 

0 

En fin de saisie, une delegation des factures saisies a I'affactureur est effectuee en Ugne, par 
une personne habHitee, cote vendeur. Pour obtenir un caractere certain, juridiquement, cet 

..t^. Af^. H/^,lepation de factures est accompagne d'une certification 61ectronique, sur la base 

par exemple de clefs publiques PKI, d6fini6s par un tiers de confiance. Si des raisons 
25 juridiques justifient une preuve suppl6mentake, une version imprim6e des factures saisies 
est etablie, et retoumee dument signee k I'affactureur. L-impression peut se faire imm6diate- 
ment, soit sur la base des informations saisies c6t6 vendeur, soit sur la base d'un retour de 
fichier k imprimer, depuis I'affectureur vers le vendeur. 

3 0 Apartir de Ik, I'affactureur peut mener la mission qui lui est d^leguee, k savoir encaisser les 
factures auprfes des acheteurs, et les relancer au besoin. 

Le vendeur peut egalement demander k I'affactureur: 
- de garantir le paiements de factures en instance, et/ou 
35 -de lui consentir un credit sur la base des paiements de factures en instance. 

Ces demandes s'effectuent avec la mSme securite et le m6me caractere certain que la saisie 
des factures en Ugne. 
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Ainsi, rinvention permet bien d'effectuer en ligxie, sur tin reseau etendu, done ouvert, la 
saisie de documents de grande taille ayant valeur juridique entre les parties, de fagon sure 
et certifiable. 



5 On pent en outre obtenir une correspondance etroite entre la version saisie a Tecran et la 
version papier d'accompagnement. 



Par la suite , un operateur du vendeur pourra consulter son ou ses comptes, toujours h. r6cran 
et sur son poste distant. 

10 

L'affactureur doit d^livrer au vendeur des documents de compte rendu, h caractSre 
syst6niatique et/ou periodique. Par ailleurs, des personnels de Taffactureur gerent les 
comptes des vendeurs, et sont a disposition des vendeurs pour repondre en ligne a leurs 
questions. On a decrit IHisage des fichiers natifs en interne chez Taffactureur. lis permettent 
15 d'etablir plusieurs versions d'un meme document imprime ou visualise, tout en faisant en 
sorte que les presentations du contenu, dans les differentes versions soient identiques ou tres 
proches. Ceci contribue de maniere considerable a faciliter le travail et la discussion a. 
distance entre les vendeurs et les personnels de Taffactureur. 

2 0 Ainsi, les moy ens decrits permettent une avancee considerable vers un traitement a distance 
de Taffacturage. On pent ainsi limiter au maximum les frais de saisie informatique, aussi ■ 
bien que les frais de gestion des comptes, au niveau des compte-rendus et du dialogue avec 
les vendeurs. 

25 Lors de Tinteraction a distance, les operations e£fectu6es par le systSme peuvent 6tre les 
suivantes : 

- verijBer Tidentification du vendeur, 

- debuter une session vendeur par la creation d'un objet vendeur et d'un jeton imique 
attribue a cet objet vendeur, ce jeton identifiant Tavancement de la session du vendeur et 

30 Pobjet vendeur contenant le deroulement de la session jusqu*a I'etat courant de son 
avancement, 

- en reponse a une demande de saisie du vendeur associee au jeton, renvoyer du serveur un 
formulaire de saisie associe au jeton, 

- enregistrer les informations saisies regues en retour avec le jeton, 

35 - verifier la validation de ces informations par le vendeur, puis la certification par un code 
personnel (PIN) d'une entite autorisee h certifier pour ce vendeur. 

- aubesoin, g^nerer un fichier d'impression prevu pour etre retoume conmcne document signe 
par le vendeur. 
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C6t6 serveur d'affacturage (versl'ext6rieur), cela peutfaire intervenir les elements suivants: 

- une fonction d'identification d'un vendeur sur reception d'un identifiant de vendeur, 

- une premiere fonction de creation, pour creer un objet vendeur, avec un identifiant de 
vendeur, 

5 - une deuxieme fonction de creation, pour creer un jeton unique, 

- une fonction d'attribution d'un jeton cree k un objet vendeur, un objet vendeur auquel est 
attribue un jeton d6finissant une session de vendeur, 

- un conteneur pour stocker chaque objet vendeur et son jeton attribu6, 

- une fonction de recherche d'identifiant de vendeur dans les objets vendeur du conteneur, 
10 - une fonction d'6change entre au moins le serveur de services et le ou les postes vendeurs 

pour utiliser le jeton lois d'6changes d'informations durant la session du vendeur, le jeton 
permettant d'etablir r6tat en cours de la session. 

Apartir de Ik, le serveur de service est agenc6 pour appeler la fonction d'identification, la 
1 5 deuxieme fonction de creation et la fonction de recherche sur la demande d'un vendeur pour 
ouvrir une session de vendeur, puis pour appeler soit la premiere fonction de creation et la 
fonction d'attribution, soit la fonction d'attribution seule en fonction notamment du r6sultat 
de la fonction de recherdie, et ensuite pour appeler la fonction d'echange. 



Aimexe Al 
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Table 1 - d6but de fichier 


Item 


Pos. 


Len. 


Type 


\/a/. 


rec code 


1 


1 


N 


1 


soc id 


2 


2 


A 




filler 


4 


30 






version No 


34 


2 


A 




Creat Date 


36 


8 


N 




Effect Date 


44 


8 


N 




Rle class 


52 


20 


A 




Rlier 


72 


169 


N 




241 

Table 2 - corps de fichier 


Item 


Pos. 


Len. 


Type 


Va/. 


rec code 


1 


1 


N 


2...8 


soc id 


2 


2 


A 




vend id 


4 


6 


N 




Doc^type 


10 


4 


A 




PageNolnDoc 


14 


3 


N 




PrintSide 


17 


1 


A 




Data_pos 


18 


6 


N 




PrintAttrib 


24 


6 


N 




Grapti_elmts 


30 


4 


N 




UneJump 


34 


2 


N 




Filler 


36 


5 


A 




Data Content 


41 


200 


A 




241 

Table 3 - fin de fichier 


Item 


Pos. 


Len. 


Type 


Val. 


rec code 


1 


1 


N 


9 


soc id 


2 


2 


A 




filler 


4 


30 






version No 


34 


2 


A 




NbOfRec 


36 


8 


N 




Rller 


44 


197 






241 
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Revendi cations 

1. Sy Sterne informatique, comprenant : 

- une interface resean (50), propre k imtialiser une connexion avec un poste distant (91), 
5 - un gestionnaire de memoire (410), propre a creer et maintenir un espace memoire d6die I 

un poste distant, pour Techange de donn6es entre le systeme et ce poste distant (91), et 

- un gestioimaire de session (410), reagissant a une initialisation de connexion avec 
identification reussie en ouvrant une session de poste distant (91), assod^e a un jeton unique 
(315T), et a un espace memoire dedie au poste distant dans le gestionnaire de memoire, 

10 - les echanges de donnees avec le poste distant (91) au cours d'une session etant condition- 
nes par la presence du jeton associe. 

2. Systeme informatique selon la revendication 1, caracterise en ce que le gestionnaire de 
memoire (410) est agence pour definir ledit espace memoire dedie en tant qu'objet logiciel, 

15 associ6 a IMdentifiant et au jeton unique. 

3. Systeme informatique selon la revendication 2, caract6rise en ce qu'il comprend un 
conteneur (414) propre h stocker une correspondance entre des objets logiciels et des jetons 
uniques qui leur sent attribu6s. 

20 

4. Systfeme informatique selon la revendication 3, caracteris6 en ce que le gestionnaire de 
session (410) est agence pour, aprds identification r6ussie, rechercher un objet logiciel 

cQixespQnd^Rt-gt-Gette4dentifiea^on7^7^4^ pus le d is l an t (91), comme 

premier echange avec jeton, la faculte de reprendre une tache sur cet objet logiciel, ou de 
2 5 I'abandonner pour en creer un nouveau associe a ime nouvelle tache, 

5. Systeme informatique selon Tune des revendications precedentes, caract6rise en ce que 
le jeton unique est obtenu par la concatenation du resultat d 'une fonction aleatoire sur la date 
courante, Theure courante et une valeur aleatoire. 

30 

6. Systeme informatique selon Tune des revendications pr6cedentes, caract6rise en ce que 
le gestionnaire de session (410) de vendeur est agenc6 pour offirir a un poste distant (91) une 
fonction de saisie de donn6es (320), ime fonction de validation de donn6es saisie, et au 
moins une fonction de post-traitement apres saisie validee. 

35 

7. Systfeme informatique selon Tune des revendications pr6cedentes, caracterise en ce qu'il 
comprend une application de saisie k distance, offerte au poste distant (91), Tespace 
memoire (419) dedie etant consacre au stockage temporaire de donn6es saisies, en attente 
de validation. 
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8. Systeme informatique selon la revendication 7, caract€rise en ce que les donn€es saisies 
sont des donnees de factures, souimses h. distance k une entite d'affacturage, par irn poste 

5 distant (91) de vendeur. 

9. Systeme informatique selon la revendication 8, caracterise en ce que le gestionnaire de 
session (410) est agence pour offrir, a un poste distant (91) de vendeur, une fonction de 
saisie de factures (320), une fonction de validation de factures saisies pour remise en 

10 affacturage, une fonction de demande d'approbation de credit (321) sur factures remises en 
affacturage, et une fonction de consultation de compte (322) chez I'affactureur. 

10 . Systfeme informatique selon la revendication 9, caracteris6 en ce qu'en mode de saisie 
de factures, le gestionnaire de session (410) opere par envoi au poste distant (91) d'un 
15 foimulaire de saisie, avec attente d'un retour du formulaire complete, k chaque fois 
acconq}agn6 du jeton unique correspondant 

11. Systeme informatique selon I'une des revendications 9 et 10, caracterise en ce quel 
gestionnaire de session (410) est agenc6pour subordonner aumoins lafonction de validation^ 

20 de factures saisies pour remise en affacturage k une certification fond6e sur un code • 
personnel (PIN) de la part d'un acteur habilite c6t6 vendeur. v 

12. Systeme informatique selon I'une des revendications 9 k 11, agenc6 comme un serveur 
d'6changes cooperant avec un serveur interne, caracterise en ce que le serveur d'6changes 
est agency pour transmettre les saisies valid6es au serveur interne, lequel assure la tenue de 
comptes et les operations connexes, selectivement pour chaque entite vendeur. 
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13. Systfeme informatique selon la revendication 12, caracterise en ce que la validation 
definitive est conditionn6e par I'envoi d'un autre document signe par le vendeur, par un 

30 moyen autre que le r6seau 6tendu. 

14. Systeme informatique selon I'une des revendications 12 et 13, caract6ris6 en ce que le 
gestionnaire de session (410) est agencS pour ofErir aussi, h un poste distant (91) de vendeur, 
une fonction de demande de garantie sur des factures saisies. 
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15. Systeme informatique selon I'une des revendications 12 a 14, caracterise en ce qu'il 
comprend un generateur d'un fichier natif d'impression, relatif une impression k caractere 
probant, tiree d'un ensemble coherent de donnees presentes dans le serveur mterne, et un 
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gestionnaire de documents capable de tirer de ce fichier natif des impressions orientees 
comptes selon differents foraiats. 

16. Systeme informatique selon la revendication 15, caracterise en ce que le gestionnaire 
de documents comprend : 

- un accesseur (605) de fichier natif, capable de reagir a un identifiant de document en 
selectionnant une portion correspondante du fichier natif, et 

- au moins deux constructeurs de visualisation/impression, capable de cooperer avec 
Taccesseur (605) de fichier natif pour construire deux fichiers de visualisation/impression, 
correspondant a un meme contenu imprimable, ces deux constructeurs de visualisa- 
tion/hnpression operant sur des formats de fichier differents, 

- ce qui permet de disposer, en interne et chez les vendeurs, de documents directement 
comparables, imprimes et/ou a Tecran. 

17. Systeme informatique selon la revendication 16, caract6ris6 en ce que les constructeurs 
de visualisation/impression comprennent un constructeur de visualisation/impression 
operant au format pdf . 

18. Systfeme informatique selon la revendication 16, caracterise en ce que les constructeurs 
de visualisation/impression comprennent un constructeur de visualisation/impression 
operant selon un format de fichier image. 

_J^uaysteme4nfannatique^elonJa.re.vend 
de visualisation/impression comprennent un constructeur de visualisation/impression 
operant selon un fomiat de fichier d'echange, propre a etre transmis pour impression en 
masse. 

20.Systeme informatique, comprenant un serveur d^affacturage, propre & g6rer des comptes 
de vendeurs etablis sur la base de factures remises par chaque vendeur k TaflFactureur, en 
fonction des encaissements de factures aupres d'acheteurs, de fagon connue en soi, ainsi 
qu'un serveur d' applications vers rext6rieur, pour des postes distants, 
caract6ris6 en ce que le serveur d' applications vers l'ext6rieur est agence pour travailler en 
r6seau 6tendu avec un ou des postes distants de vendeurs, et pour r6pondre a un identifiant 
de vendeur pour une demande de saisie d'informations, en operant une application de 
traitement de demande qui est propre : 

- a verifier T identification du vendeur, 

- a debuter la session vendeur par la creation d'un objet vendeur et d'un jeton unique 
attribue a cet objet vendeur, ce jeton identifiant r avancement de la session du vendeur et 



I'objet vendeur contenant le deroulement de la session jusqu'k l'6tat courant de son 

avancement, 

- k envoyer une demande de saisie du vendeur associ6e au jeton h un serveur reponsepropre 
h. renvoyer un formulaire de saisie associ6 au jeton, 

- a enregistrer les informations saisies regues en retour avec le jeton, et 

- k verifier la validation de ces informations par le vendeur, puis la certification par un code 
personnel (PIN) d'une entite autorisee h certifier pour ce vendeur. 

21. Systfeme informatique selon la revendication 20, caracterise en ce que ladite application 
de traitement de demande est propre en outre 

- k gfinerer un fichier d'impression prevu pour Stre retourn6 comme document signd par le 
vendeur. 



22. Systferae informatique, comprenant un serveur de services d'affacturage interconnects 
en r6seau etendu avec un ou des postes vendeurs, caract6ris6 en ce que 
le serveur de services d'affacturage comprend 

- une fonction d'identification d>un vendeur sur reception d'un identifiant de vendeur, 

- une premiere fonction de creation d'un objet vendeur, un objet vendeur comprenant un 
identifiant de vendeur, 

- une deuxidme fonction de creation d'un jeton unique, V 

- une fonction d'attribution d'un jeton cree k un objet vendeur, un objet vendeur auquel esC 
attribu6 un jeton definissant une session de vendeur, 

- un conteneur pour stocker chaque objet vendeur et son jeton attribud, 

- une fonction de recherche d'identifiant de vendeur dans les objets vendeur du conteneur, 

- une fonction d'6change entre au moins le serveur de services et le ou les postes vendeurs 
pour utiliser le jeton lors d'dchanges d'informations durant la session du vendeur, le jeton 
pemiettant d'etablir I'etat en cours de la session, 

le serveur de service etant propre a appeler la fonction d'identification, la deuxieme fonction 
de creation et la fonction de recherche sur la demande d 'un vendeur pour ouvrir une session 

devendeur,propreaappelersoitlapremierefonctiondecr6ationetlafonction d'attribution, 
soit la fonction d'attribution seule en fonction d'au moins le r6sultat de la fonction de 
recherche, et propre k appeler dgalement la fonction d'echange. 
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